Problem

A stdio mcp_server orphaned by a dropped SSH session (ssh <host> python3 -m mempalace.mcp_server) swallows pipe errors in the generic exception handler and sleeps forever on the dead channel — while continuing to hold whatever palace locks it acquired. In our production palace (~110k drawers) an orphan held the mine_palace flock idle for ~4 hours, blocking every write until the process was found and killed manually.

The writer-lease self-heal work (#1960, #1971) covers lease recovery after a peer exits — but an orphan that never exits never releases anything. This closes that gap at the source.

Fix

The stdio protocol loop now shuts down cleanly on:

• stdin EOF — client disconnected;
• OSError reading stdin — EIO/EBADF from orphaned ptys;
• BrokenPipeError/OSError writing stdout — client side of the pipe gone.

Shutdown returns from the loop for a normal interpreter exit 0 — no os._exit — so held flocks release via ordinary process teardown. A broken stdout is re-pointed at /dev/null first (_drop_broken_stdout), so the interpreter's final flush of the half-written response can't re-raise BrokenPipeError and turn a clean exit into status 120.

Tests

tests/test_mcp_server_eof.py spawns the real server as a subprocess and kills its stdio channel from the outside:

• closing stdin → process exits 0 promptly;
• killing the reader side of stdout mid-response → process exits 0, no traceback spam.

Palace isolation via the existing conftest HOME redirect (same mechanism as test_mcp_stdio_protection.py).

Running in production on our fork since 2026-07-12 with no orphan recurrence.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NQ7ZKnXm7pnmJ5gVaNhLE4